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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the stage 3 specification of the S9 reference point for the present release. The functional 
requirements of stage 2 specification for the S9 reference point are contained in 3GPP TS 23.203 [2]. The S9 reference 
point lies between the PCRF in the home PLMN (also known as H-PCRF) and the PCRF in the visited PLMN (also 
known as V-PCRF). 

Whenever it is possible the present document specifies the requirements for the protocols by reference to specifications 
produced by the IETF within the scope of Diameter. Where this is not possible extensions to Diameter are defined 
within the present document. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.203: "Policy and Charging Control Architecture" 

[3] 3GPP TS 29.212: "Policy and charging control over Gx reference point" 

[4] 3GPP TS 29.213: "Policy and charging control signalhng flows and Quality of Service (QoS) 

parameter mapping" 

[5] 3GPP TS 29.214: "Policy and charging control over Rx reference point" 

[6] IETF RFC 3588: "Diameter Base Protocol". 

[7] 3GPP TS 29.229: "Cx and Dx interfaces based on the Diameter protocol; Protocol details" 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

Home Routed Access: Roaming scenario where the PCEF is located in the HPLMN. In a Home Routed roaming 
scenario, the UE obtains access to the packet data network from the HPLMN. 

Visited Access (also known as local breakout): Roaming scenario where the PCEF is located in the VPLMN. In a 
Visited Access Roaming scenario, the UE obtains access to the packet data network from the VPLMN. 

Editor" s Note: These definitions can be reformulated when they are included in stage 2 specifications. 
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3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AF Application Function 

AN-Gateway Access Network Gateway 

AVP Attribute- Value Pair 

BBERF Bearer Binding and Event Reporting Function 

H-AF Home AF 

H-PCRF Home PCRF 

HPLMN Home PLMN 

HR Home-Routed 

OCS Online charging system 

OFCS Offline charging system 

PCC Policy and Charging Control 

PCEF Policy and Charging Enforcement Function 

PCRF Policy and Charging Rule Function 

S-GW Serving Gateway 

VA Visited Access 

V-AF Visited AF 

V-PCRF Visited PCRF 

VPLMN Visited PLMN 



S9 Reference Point 



4.1 



Overview 



The S9 reference point is used in roaming scenarios involving a HPLMN and a VPLMN. Two main roaming scenarios 
are considered: visited access (PCEF in VPLMN and AF in VPLMN or HPLMN) and home-routed access (PCEF in 
HPLMN and AF in the HPLMN). 

Two Diameter applications are used over the S9 reference point: S9 and Rx. The purpose of the S9 Diameter 
application is to install PCC rules or QoS rules generated in the HPLMN into the VPLMN and transport the events that 
may occur in the VPLMN to the HPLMN. When the AF is in the VPLMN, Rx is used over the S9 reference point to 
exchange service session information from the V-PCRF to the H-PCRF. 

The AF exchanges session information with the H-PCRF or V-PCRF as specified in 3GPP TS 29.214[5]. The PCRF 
(H-PCRF and/or V-PCRF) exchanges PCC rules and QoS rules with the PCEF and BBERF respectively as specified in 
3GPPTS29.212[3]. 

Signalling flows related to all the PCC reference points (Gx, Gxx, Rx and S9) are specified in 3GPP TS 29.213[4]. 



4.2 



Reference model 



The S9 reference point is defined between the V-PCRF and the H-PCRF for home routed access and visited access. 

NOTE 1: AN-Gateway refers to the S-GW when the Gxc applies and to a trusted non-3GPP access gateway when 
Gxa applies. 

The relationships between the different functional entities involved in the home routed access are depicted in figure 
4.2.1. 
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Figure 4.2.1 : S9 reference point at the PCC archiitecture for roaming with) home routed access 

The relationships between the different functional entities involved in the visited access are depicted in figure 4.2.2. 
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Figure 4.2.2: S9 reference point at the PCC architecture for roaming with visited access 

NOTE 2: AF can be located in both VPLMN and HPLMN for the visited access. 
For a visited access, the VPLMN may use an OCS proxy between the PCEF and the OCS. 

NOTE 3: The H-PCRF can optionally send the addresses of the proxy/OCS to the V-PCRF. 



4.3 



Functional elements 



4.3.1 H-PCRF 

The H-PCRF (Home Policy and Charging Rules Function) is a functional element that encompasses policy control 
decision and flow based charging control functionalities in the HPLMN. 

The H-PCRF provides functions for both home routed access and visited access. 

When provisioning PCC/QoS rules over the S9 reference point, the H-PCRF is responsible for assigning packet filter 
identifiers for rules provisioned as a result of UE initiated resource modification. 



ETSI 



3GPP TS 29.21 5 version 8.2.0 Release 8 1 ETSI TS 1 29 21 5 V8.2.0 (2009-06) 

4.3.1.1 Home routed access 

The H-PCRF shall provision QoS Rules to the V-PCRF via the S9 reference point and PCC Rules to the PCEF via the 
Gx reference point. The H-PCRF ensures that the QoS Rules provisioned are aligned with the PCC Rules. 

The H-PCRF PCC Rule decisions may be based on one or more of the following: 

Information obtained from the AF via the Rx reference point. 

Information obtained from the V-PCRF via the S9 reference point. 

NOTE: The above may include information obtained from the BBERF via the Gxx reference point. 

Information obtained from the PCEF via the Gx reference point 

- Information obtained from the SPR via the Sp reference point. 
PCRF pre-configured information. 

The H-PCRF provisions event triggers to the V-PCRF and PCEF. 

4.3.1.2 Visited Access 

The H-PCRF shall provision PCC Rules to the V-PCRF via the S9 reference point. 
The H-PCRF PCC Rule decisions may be based on one or more of the following: 

Information obtained from the AF when located in the home network 

Information obtained from the V-PCRF via the S9 reference point. 

NOTE: The above may include information obtained from the AF when the AF is located in the VPLMN and 
information obtained from the PCEF or BBERF. 

- Information obtained from the SPR via the Sp reference point. 
PCRF pre-configured information. 

The H-PCRF provisions event triggers to the V-PCRF, 

4.3.2 V-PCRF 

The V-PCRF (Visited Policy and Charging Rules Function) is a functional element that encompasses policy control 
decision and flow based charging control functionalities in the VPLMN. 

The V-PCRF provides functions for both home routed access and visited access. 

4.3.2.1 Home routed access 

The V-PCRF shall request QoS Rules and report events to the H-PCRF via the S9 interface. 

The V-PCRF validates the QoS parameters received within the QoS Rules based on operator policies. The V-PCRF 
informs the H-PCRF if the QoS validation failed. 

The V-PCRF shall provision QoS Rules to the BBERF via the Gxx reference point. 

4.3.2.2 Visited access 

The V-PCRF shall request PCC Rules from and report events to the H-PCRF using the S9 reference point. 

The V-PCRF extracts the QoS Rules from the PCC Rules, validates the former, and if QoS validation is successful, the 
V-PCRF shall provision the PCC Rules to the PCEF via the Gx reference point and the QoS Rules to the BBERF via 
the Gxx reference point. If the QoS validation fails the V-PCRF shall reject the request. For case 2a, there may be 
additional specific rules to be installed at the BBERF for the sole purpose of allowing the tunnel between the BBERF 
and the PCEF not directly related with any service. 
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When the AF is located in the VPLMN, the V-PCRF shall exchange Rx messages with the H-PCRF over the S9 
reference point. 

4.4 PCC Rules and QoS Rules 

4.4.1 PCC Rule definition 

The purpose of the PCC Rule is defined in 3GPP TS 29.212 [3]. PCC Rules are sent over S9 interface for visited access. 

There are two different types of PCC rules as defined in 3GPP TS 29.212 [3].: 

Dynamic PCC rules. Dynamically provisioned by the H-PCRF to the V-PCRF via the S9 interface. These PCC 
rules may be either predefined or dynamically generated in the H-PCRF. Dynamic PCC rules can be installed, 
modified and removed at any time. 

Predefined PCC rules. Preconfigured in the PCEF. Predefined PCC rules can be activated or deactivated by the 
H-PCRF at any time via the V-PCRF using S9 interface. Predefined PCC rules may be grouped allowing the H- 
PCRF to dynamically activate a set of PCC rules in the PCEF via the V-PCRF using S9 interface. 

The content of a PCC Rule is the same as defined in 3GPP TS 29.212 [3]. The rule name within a PCC Rule shall be 
used to reference to a PCC Rule in the communication between the H-PCRF and the V-PCRF. 

4.4.2 QoS Rule definition 

The purpose of the QoS Rule is defined in 3GPP TS 29.212 [3]. QoS Rules are sent over S9 interface for home routed 
access and visited access. 

The content of a QoS Rule is the same as defined in 3GPP TS 29.212 [3]. The rule name within a QoS Rule shall be 
used to reference to a QoS Rule in the communication between the H-PCRF and the V-PCRF. 

4.4.3 Operations on PCC rules 

PCC Rules operations are defined in 3GPP TS 29.212 [3]. This clause clarifies how those operations are implemented 
on the S9 interface. 

For dynamic PCC rules, the V-PCRF validates the QoS parameters requested within the PCC Rules, before accepting 
the installation or modification of PCC Rules. If the QoS validation fails the V-PCRF rejects the installation or 
modification of the PCC Rule. 

For the Visited Access case, the H-PCRF may activate predefined PCC rules in the V-PLMN"s PCEF. In that case, the 
V-PCRF shall validate, based on roaming agreements, that the H-PCRF is allowed to perform a particular operation on 
a particular PCC Rule. 

4.4.4 Operations on QoS Rules 

QoS Rules operations are defined in 3GPP TS 29.212 [3]. 

For QoS rules, the V-PCRF validates the QoS parameters requested within the QoS Rules, before accepting the 
installation or modification of QoS Rules. If the QoS validation fails the V-PCRF rejects the installation or modification 
of the QoS Rule. 

4.5 PCC procedures over S9 Reference Point 
4.5.1 General 

In this release, there are two protocols running over the S9 interface: the S9 protocol and the Rx protocol. 
The Rx protocol is working as specified in 3GPP TS 29.214 [5]. 
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The S9 protocol is defined in clause 5 in this document. The S9 protocol allows establishment, modification and 
termination of Diameter S9 sessions. There is an S9 session per UE between each H-PCRF and V-PCRF pair. 
An S9 session can contain zero, one or several S9 subsessions. The S9 subsession scope is per PDN connection. 
An S9 subsession can be established, modified and terminated. 

When the V-PCRF receives a request that should be sent to the HPLMN, the V-PCRF places the information within a 
S9 subsession level if it only applies to a particular PDN connection. Otherwise, the information is placed at S9 session 
level. 

There are three distinct network scenarios for an IP -CAN as defined in 3GPP TS.29.213 [4]: 

1. No Gateway Control session is needed. GTP is used for S5/S8 reference points. 

2. Gateway Control session is needed. Two subcases can be distinguished: 

2a) S2c reference point (and then DSMIPv6 protocol) is used by a trusted non-3GPP access to access the 
EPC. 

2b) Trusted non-3GPP accesses that use S2a reference point (PMIPv6 or MIPv4 protocol is used) or 3GPP 
access that uses PMIPv6 over S5/S8 reference points. 

The S9 reference point is used for case 1 in VA scenario and, for cases 2a and 2b for both HR and VA scenarios. 

NOTE: The cases described above are oftenly referred through the document as cases 1, 2a or 2b. 

4.5.1.1 S9 Session Establishment 

When the V-PCRF receives a CCR command with CC-Request-type AVP set to the value 'TNITIAL_REQUEST" from 
the PCEF/BBERF that can not be associated with any existing S9 session to the H-PCRF for that UE (based on the 
Subscription-ID AVP), the V-PCRF shall establish a new S9 session according to the procedures specified in clause 

4.5.2.1 or 4.5.3.1 for home-routed and visited access respectively. 

NOTE: In a network scenario that deploys case 1 as defined in clause 4.5.1, S9 session is only needed in the 
visited access case and the procedures described in clause 4.5.3 apply. 

4.5.1 .2 S9 Session Termination 

The V-PCRF shall initiate a termination of the S9 session when it receives a trigger that originates the removal of the 
last existing S9 subsession associated with the referred S9 session. The V-PCRF terminates the S9 session following the 
procedures described in clause 4.5.2.3 or clause 4.5.3.3. 

When the H-PCRF determines that the S9 session shall be terminated, the procedures described in clause 4.5.2.4 and 
4.5.3.4 apply. 

NOTE: In a network scenario that deploys case 1 as defined in clause 4.5.1, only the procedures described in 
clause 4.5.3 apply. 

4.5.1.3 Event Triggers 

4.5.1 .3.1 Provisioning of Event Triggers 

Provisioning of event triggers may be performed by either the V-PCRF or the H-PCRF. The V-PCRF may receive 
requests to subscribe to event triggers from the H-PCRF, from the PCEF (VA case) or due to an internal or other 
external event. The H-PCRF may receive subscription request from the PCEF (i.e. In the HR case, the H-PCRF derives 
the event triggers from the Event-Report-Indication AVP from the PCEF), or due to an internal or external event (e.g. 
due to an Rx interaction with the AF). 

When the H-PCRF wants to subscribe or unsubscribe to event trigger(s) in the VPLMN, the H-PCRF shall provide to 
the V-PCRF one or several event triggers by including them within the Event-Trigger AVP. Event Triggers may apply 
to a specific S9 Subsession(s) or to a specific S9 session. Event Triggers provided for a specific S9 session apply to S9 
subsession(s) within the specified S9 session. 
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When Event Triggers are provided for a specific S9 subsession(s), the H-PCRF includes Subsession-Decision- 
Info AVP for each of the affected S9 subsession. Each Subsession-Decision-Info AVP includes the Subsession- 
Id AVP and the list of event triggers within the Event-Trigger AVP. 

When Event Triggers are provided for a specific S9 session(s), the H-PCRF includes the list of event triggers 
within the Event-Trigger AVP at command level. 

The H-PCRF adds new event triggers or removes previously provided event triggers to the V-PCRF by providing the 
new complete list of applicable event triggers. 

The H-PCRF may provision event triggers to the V-PCRF using both a RAR and a CCA command. 

When the V-PCRF receives event triggers from the H-PCRF, the V-PCRF stores them locally as S9-related and 
proceeds as follows: 

• In both the Home-Routed and Visited Access cases, the V-PCRF shall provision the event triggers over the 
associated Gxx session to the BBERF using the Gateway Control and QoS Rules Provisioning or Gateway 
Control Session Establishment procedure described in 3GPP TS 29.212 [3] clauses 4a.5.1 and 4a. 5. 2. 

• Additionally, in the Visited Access case, the V-PCRF may also provision the event triggers over the associated 
Gx session to the PCEF using the PCC Rule Provisioning procedure described in in 3GPP TS 29.212 [3] clause 
4.5.3. 

The H-PCRF may remove all previously provided event triggers by providing the Event-Trigger AVP set to the value 
NO_EVENT_TRIGGERS. The H-PCRF includes within the Subsession-Decision-Info AVP the affected Subsession-Id 
AVP and the list of event triggers within the Event-Trigger AVP. When an Event-Trigger AVP is provided with this 
value, no other Event-Trigger AVP shall be provided in the CCA or RAR command. Upon reception of an Event- 
Trigger AVP with this value from the H-PCRF, if there are no other locally handled event triggers, the V-PCRF shall 
provide the Event-Trigger AVP set to the value NO_EVENT_TRIGGERS to the BBERF and PCEF; if there are locally 
handled event triggers, the V-PCRF shall update the event triggers at the BBERF and the PCEF to remove those 
triggers previously installed based on requests from the H-PCRF. The V-PCRF shall not inform H-PCRF of any 
subsequent event except for those events that are always subscribed with no provision. 

When the PCEF in the Visited Access case subscribes or unsubscribes to one or several event triggers with the V- 
PCRF, the V-PCRF stores them locally as Gx-related events and then provision them over the associated Gxx session 
(identified using the Gateway Control Session to IP-CAN session linking procedure described in 3GPP TS 29.212 [3] 
clause 4a. 5. 6) to the BBERF using the Gateway Control and QoS Rules Provisioning procedure described in 3GPP TS 
29.212 [3] clause 4a.5.2. 

The V-PCRF may also provision event triggers to the BBERF/PCEF due to an internal or external trigger or using the 
Provisioning of Event Triggers procedure as described in 3GPP TS 29.212 [3] clauses 4a. 5. 3. and clause 4.5.3. 

4.5.1 .3.2 Reporting of deployed Event Triggers 

The V-PCRF may receive a report of an event trigger that is deployed at the BBERF or at the PCEF (VA case). 

In the VA case, when the event trigger reported by the BBERF corresponds to a Gx-related event trigger (i.e. a 
subscription from the PCEF), the V-PCRF notifies the PCEF as described in 3GPP TS 29.212 [3] clause 4.5.2.1. 

When the event trigger reported by the BBERF or the PCEF (in VA case) corresponds to a S9-related (i.e. a 
subscription from the H-PCRF) event trigger, the V-PCRF notifies the H-PCRF using the procedures as described in 
clause 4.5.2.1 in home routed case or the PCC Rule Request procedure as described in clause 4.5.3.1 for visited access 
case. 

When the event trigger reported by the BBERF/PCEF corresponds to a V-AF-related event trigger, the V-PCRF shall 
inform the V-AF using the RAR command including the Specific-Action AVP as described in 3GPP TS 29.214 [5] 
clauses 4.4.6.1, 4.4.6.2 and 4.4.6.3. 

4.5.1 .4 Multiple BBERF scenarios 

The multiple BBERF scenarios happen when there is a change of BBERF and the H-PCRF and the V-PCRF needs to 
handle more than one BBERF related with the same UE. 
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The V-PCRF shall follow the procedures defined in clauses 4.5.2.5 and 4.5.3.5 respectively for the home routed and 

visited access cases. 

NOTE: For all cases the H-PCRF subscribes to IP-CAN_CHANGE events. 

4.5.1 .5 Provisioning and validation of Default EPS Bearer authorized QoS 

The default EPS Bearer QoS handling only applies to case 2b in HR scenario, and case 1 and case 2b in the VA 
scenario. 

For IP-CAN types that support multiple IP-CAN bearers, the V-PCRF may provide the Default-EPS -Bearer-QoS AVP 
in the Subsession-Enforcement-Info AVP within the CCR command to the H-PCRF. 

The H-PCRF may provision the authorized QoS for the default EPS bearer within the corresponding S9 subsession in 
the CCA command including the Subsession-Decision-Info AVP for the S9 subsession within the S9 session. The S9 
Subsession-Decision-Info AVP contains the Default-EPS-Bearer-QoS AVP. 

Besides the H-PCRF may provision the authorized QoS for the default EPS bearer without receiving a request from the 
V-PCRF, e.g. in response to an internal trigger within the H-PCRF or upon interaction with the SPR. The H-PCRF shall 
send a RAR command including the Subsession-Decision-Info AVP with the Default-EPS-Bearer-QoS AVP for the S9 
subsession within the S9 session. 

The V-PCRF shall validate the Default-EPS-Bearer-QoS AVP in case it is received in the CCA or RAR command. If 
the QoS validation fails, the V-PCRF shall reject the request using a CCR/RAA command respectively to the H-PCRF. 
The CCR/RAA shall include the Subsession-Enforcement-Info AVP for the affected S9 subsession that includes the S9 
subsession identifier within the Subsession-Id AVP, the QoS -Information AVP to indicate the acceptable QoS, and 
either the Charging-Rule-Report (VA scenario) or the QoS-Rule-Report (HR scenario) with the Rule-Failure-Code AVP 
set to UNSUCCESSFUL-QOS-VALIDATION value. 

4.5.2 Home-Routed access 

4.5.2.1 S9 Session/Subsession establishment/modification 

The V-PCRF interacts with the H-PCRF in the following instances: 

1) Upon Gateway Control Session establishment over Gxx: 

When the V-PCRF receives a CCR command with a CC-Request-Type AVP set to 'TNITIAL_REQUEST" from 
the BBERF over Gxx, the V-PCRF determines whether case 2a or case 2b applies as defined in 3GPP TS 29.213 
[4] and applies the following procedures: 

If case 2a applies. 

If there is not an already established S9 session for this roaming user, the V-PCRF shall send to the H- 
PCRF a CCR command with the CC-Request-Type AVP set to the value "INITIAL_REQUEST" to 
establish a new S9 session. The CCR command from the V-PCRF to the H-PCRF shall include those 
attributes provided by the BBERF to the V-PCRF at the Diameter CCR command level, defined in clause 
4a.5.1of3GPPTS 29.212 [3]. 

Otherwise, if there is an already established S9 session for this roaming user, the procedures in clause 
4.5.2.5 shall be applied. 

If case 2b applies. 

If there is not an already established S9 session for this roaming user, the V-PCRF shall send to the H- 
PCRF a CCR command with the CC-Request-Type AVP set to the value "INITIAL_REQUEST" to 
establish a new S9 session. The V-PCRF shall include the Subsession-Enforcement-Info AVP within the 
CCR command with a new S9 subsession identifier assigned by the V-PCRF within the Subsession-Id 
AVP, the Subsession-Operation AVP set to the value "ESTABLISHMENT". The V-PCRF shall map the 
Gxx session-id(s) to the corresponding subsession-id(s) in the S9 session. In addition, the V-PCRF shall 
include those attributes provided by the BBERF that allows the H-PCRF to identify the Subsession as 
defined in 3GPP TS 29.212 [3]. 
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If an existing S9 session for the roaming user is already established with the H-PCRF, the V-PCRF shall 
update the existing session by sending a CCR with the CC-Request-Type AVP set to the value 
'UPDATE_REQUEST' to the H-PCRF. 

If an S9 subsession does not exist for the PDN connection corresponding to the gateway control session 
establishment, the V-PCRF shall include the Subsession-Enforcement-Info AVP within the CCR 
command with a new S9 subsession identifier assigned by the V-PCRF within the Subsession-Id AVP, 
the Subsession-Operation AVP set to the value "ESTABLISHMENT". The V-PCRF shall map the Gxx 
session-id(s) to the corresponding subsession-id(s) in the S9 session. 

In all cases, the CCR command from the V-PCRF to the H-PCRF shall include, at subsession level, those 
attributes provided by the BBERF to the V-PCRF, as defined in clause 4a.5. 1 of 3GPP TS 29.212 [3]. 

If the V-PCRF detects that an S9 subsession already exists for a particular PDN connection linked to a 
different gateway control session (i.e. different Gxx session-id), the V-PCRF shall follow the procedures 
in clause 4.5.2.5. 

2) Upon Gateway Control Session modification over Gxx by receiving a Gateway Control and QoS rules request 

When the V-PCRF receives a CCR command with a CC-Request-Type AVP set to "UPDATE_REQUEST" 
from the BBERF over Gxx, the V-PCRF shall send a CCR command with a CC-Request-Type AVP set to 
"UPDATE_REQUEST" to the H-PCRF including the updated information. 

In case 2a, the V-PCRF shall include the attributes provided by the BBERF at the CCR command level. 

In case 2b, the V-PCRF shall modify the corresponding S9 subsession by including the Subsession- 
Enforcement-Info AVP within the CCR command that contains the allocated S9 subsession identifier within the 
Subsession-Id AVP, the Subsession-Operation AVP set to the value "MODIFICATION". In addition, the V- 
PCRF shall provide the Subsession-Id AVP to allow the H-PCRF to identify the subsession for which QoS Rules 
are requested. The V-PCRF shall include the attributes provided by the BBERF within the Subsession- 
Enforcement-Info AVP. 

The QoS rules are provisioned by the H-PCRF as follows: 

In case 2a, the H-PCRF shall provision QoS Rules in the CCA command by the QoS-Rule-Install AVP at the 
command level. 

In case 2b, the H-PCRF shall provision QoS Rules within the corresponding S9 subsession by issueing the CCA 
command and including the Subsession-Decision-Info AVP for the S9 subsession within the S9 session. Each S9 
Subsession-Decision-Info AVP contains the QoS-Rule-Install AVP. 

If the H-PCRF is, due to incomplete, erroneous or missing information (e.g. subscription related information not 
available or authorized QoS exceeding the subscribed bandwidth) not able to: 

1) Provision a policy decision to a specific subsession as response to the request sent by the V-PCRF, the H-PCRF 
shall send a CCA command including the Experimental-Result AVP at the command level with the 
Experimental-Result-Code AVP set to DIAMETER_ERROR_SUBSESSION (5470), including the Subsession- 
Decision-Info AVP with the rejected Subsession-Id(s) within the Subsession-Id AVP and the appropriate error 
within either the Experimental-Result-Code AVP or Result-Code AVP. 

2) Provision a policy decision to any of the S9 subsession(s) or provision a policy decision at the command level, 
the H-PCRF shall reject the request using a CCA command with the 
DIAMETER_ERROR_INITIAL_PARAMETERS (5140) within the Experimental-Result-Code AVP. 

When the V-PCRF receives a CCA command where S9 specific subsession(s) contain a specific Result-Code or 
Experimental-Result-Code AVP from the H-PCRF, the V-PCRF shall reply to the BBERF over the respective Gxx with 
a CCA command including the same result code. 

When the V-PCRF receives a CCA command with an error code within the Experimental-Result-Code AVP or Result- 
Code AVP at the command level, the V-PCRF shall reply to the BBERF over the respective Gxx interface with a CCA 
command including the same result code. 

The V-PCRF shall validate the QoS Rules contained in the CCA. If the QoS validation fails the V-PCRF shall perform 
the following: 
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1) Reply to the BBERF over Gxx with a CCA command including the Gx experimental result code 
DIAMETER_ERROR_INITIAL_PARAMETERS (5 140). 

2) If the CCR request related to the Gateway Control Session Establishment from the BBERF is rejected and either 
the S9 session or the S9 subsession(s) needs to be terminated, send a CCR command to the H-PCRF following 
the procedures specified in clause 4.5.2.3. 

3) Otherwise, send a CCR command to the H-PCRF with the CC-Request-Type AVP set to 'UPDATE_REQEST' 
and 

a) In case 2a, include the QoS -Rule-Report AVP to indicate the QoS Rules that were not accepted, including 
Rule-Failure-Code AVP set to UNSUCCESSFUL-QOS-VALIDATION value and the QoS -Information AVP 
to indicate the acceptable QoS. 

b) In case 2b, include the QoS -Rule-Report AVP within the Subsession-Enforcement-Info AVP to indicate the 
QoS Rules that were not accepted, including Rule-Failure-Code AVP set to UNSUCCESSFUL-QOS- 
VALIDATION value and the QoS-Information AVP to indicate the acceptable QoS. The V-PCRF shall 
include the S9 subsession specific information within the CCR command that includes the S9 subsession 
identifier within the Subsession-Id AVP. The Subsession-Operation AVP set to the value "TERMINATION" 
if the CCR used to request the rules was creating a new subsession. 

4.5.2.2 Provision of QoS Rules by the H-PCRF 

The H-PCRF may decide to provision QoS Rules without obtaining a request from the V-PCRF, e.g. in response to 
information provided to the H-PCRF via the Rx reference point, or in response to an internal trigger within the H- 
PCRF, or from a trigger by the SPR. The H-PCRF may also decide to provision QoS rules in response to a request for 
PCC Rules received by the H-PCRF from the PCEF that is linked with a former Gateway Control session establishment. 

To provision QoS Rules without a request from the V-PCRF, the H-PCRF shall do the following: 

In case 2a, send a RAR command including the QoS rules to be provisioned within the QoS-Rule-Install 
AVP at the command level. 

In case 2b, send a RAR command including the Subsession-Decision-Info AVP for each of the S9 
subsessions within the S9 session. Each Subsession-Decision-Info AVP contains the QoS rules to be 
provisioned within the QoS -Rule-Install AVPs. 

The V-PCRF shall validate the QoS Rules contained within each S9 subsession within the RAR command. 

If the QoS validation fails the V-PCRF shall send a reject in the RAA command to the H-PCRF. The V-PCRF includes: 

- In case 2a, a DIAMETER_PCC_RULE_EVENT (5 142) experimental result code, the QoS-Rule-Report AVP 
to indicate the QoS Rules that were not accepted, including Rule-Failure-Code AVP set to 
UNSUCCESSFUL-QOS-VALIDATION value and the QoS-Information AVP to indicate the acceptable 
QoS. 

In case 2b, the Subsession-Enforcement-Info AVP for each rejected S9 subsession. The Subsession- 
Enforcement-Info AVP with the rejected Subsession-Id(s) and a DIAMETER_PCC_RULE_EVENT (5142) 
experimental result code, including the QoS-Rule-Report AVP to indicate the QoS Rules that were not 
accepted, including Rule-Failure-Code AVP set to UNSUCCESSFUL-QOS-VALIDATION valueand the 
QoS-Information AVP to indicate the acceptable QoS. 

If the QoS validation succeeds, the V-PCRF shall initiate the Gateway Control and QoS Rules Provision procedure over 
Gxx as defined in 3GPP TS 29.212 [3] by sending an RAR command to the BBERF including the parameters from the 
RAR command received from the H-PCRF. When the V-PCRF receives the RAA from the BBERF(s), the V-PCRF 
responds to the H-PCRF as follows: 

in case 2a, the V-PCRF shall send a corresponding RAA command to the H-PCRF including the 
corresponding result code. 

in case 2b, the V-PCRF shall send a corresponding RAA command to the H-PCRF including the S9 
Subsession-Enforcement-Info AVP for each specific S9 subsession with the corresponding result code. 
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4.5.2.3 S9 Session/Subsession Termination Initiated by the V-PCRF 

This procedure is triggered by a Gateway Control Session Termination procedure over Gxx interface. When the V- 
PCRF receives a CCR command with a CC-Request-Type AVP set to 'TERMINATION_REQUEST' from the BBERF 
over Gxx, it shall acknowledge this message by sending the CCA command to the BBERF as defined in 3GPP TS 
29.212 [3]. In addition the V-PCRF shall do the following 

1) Terminate the S9 session, if as a consequence of the Gateway Control Session Termination over Gxx, the last S9 
subsession for that roaming user is terminated. In order to do that, the V-PCRF shall terminate the related S9 
session by sending a CCR command with a CC-Request-Type AVP set to 'TERMINATE_REQUEST' to the H- 
PCRF. 

When the H-PCRF receives the CCR, it shall acknowledge this message by sending a CCA to the V-PCRF. 

2) Update the S9 session, if there are remaining S9 subsessions for the roaming user. The V-PCRF shall modify the 
related S9 session by sending a CCR with a CC-Request-Type AVP set to 'UPDATE_REQUEST' to the H- 
PCRF. The V-PCRF shall include in the CCR the Subsession-Enforcement-Info and set the Subsession- 
Operation AVP to 'TERMINATION' for each S9 subsession of a particular UE that is terminated. 

When the H-PCRF receives the CCR, it shall acknowledge this message by sending a CCA to the V-PCRF. The H- 
PCRF shall include the Subsession-Decision-Info AVP within the CCA command with the removed Subsession-Id 
AVP and the Result-Code AVP. 

On receipt of the CCA command, the V-PCRF shall remove the session information stored for that Gateway Control 
Session. 

4.5.2.4 S9 Session/Subsession Termination Initiated by the H-PCRF 

The H-PCRF may request the termination of a S9 session/subsession to the V-PCRF. 

The H-PCRF decides to terminate a S9 session/subsession due to an internal trigger or trigger from the SPR. The 
following cases can be distinguished: 

If the H-PCRF considers that the S9 session has to be terminated, the H-PCRF shall send an RAR command to 
the V-PCRF indicating the termination of the S9 subsession by including the Session-Release-Cause AVP. The 
V-PCRF shall send a corresponding RAA command to the H-PCRF. 

If the H-PCRF considers that the S9 subsession has to be terminated, the H-PCRF shall send an RAR command 
to the V-PCRF indicating the termination of the S9 subsession by including the Session-Release-Cause AVP 
within the Subsession-Decision-Info AVP. When the V-PCRF receives the RAR command it shall answer it by 
issuing the corresponding RAA command. 

The V-PCRF shall trigger the termination of the corresponding Gxx session(s) over Gxx interface by applying the 
Gateway Control session termination procedures as defined in 3GPP TS 29.212 [3] clause 4a.5.3. 

4.5.2.5 Multiple BBERF Handling 

The H-PCRF distinguishes two types of BBERFs: primary and non-primary according to 3GPP TS 29.212 [3]. The V- 
PCRF interacts with the H-PCRF in the following instances: 

1) Upon Gateway Control Session establishment over Gxx: 

When the V-PCRF has received a CCR for Gateway Control Session Establishment from a new BBERF that is 
related with an existing gateway control session, the V-PCRF modifies the S9 session by sending a CCR 
command. The V-PCRF shall include the AN-GW-Address AVP to distinguish the information from the new 
BBERF and to allow the H-PCRF operating on any of the BBERF separately. 

If case 2a applies, the AN-GW-Address AVP is included at command level; 

If case 2b applies, the AN-GW-Address AVP is included at subsession level; 

When the H-PCRF receives the CCR command, the H-PCRF shall apply the procedures defined in 3GPP TS 
29.212 [3] to detect if the new BBERF is primary or not and will act accordingly by answering with a CCA 
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command. Within the CCA command the H-PCRF may include new decisions at either the command level for 
case 2a or at the subsession level for case 2b for the affected BBERF. 

If the same changes are applied to all BBERFs, the H-PCRF shall not include AN-GW-Address AVP within the 
CCA command. If different decisions are applied to different BBERFs, the H-PCRF shall include, in the CCA 
command, the AN-GW-Address AVP that was included in the CCR command and the associated QoS rules and 
event triggers for that BBERF. The H-PCRF shall provide the updated QoS rules and event triggers to the 
remaining BBERF(s) within RAR command(s) by initiating the QoS rule provision procedure for each of the 
remaining BBERF(s). In each RAR command, the H-PCRF shall include the AN-GW-Address AVP in order to 
identify the target BBERF. 

2) Upon Gateway Control Session modification over Gxx: 

When the V-PCRF receives a CCR command from any of the BBERFs for Gateway Control Session 
modification, the V-PCRF shall follow the same procedures as described above for Gateway Control Session 
Establishment case and include AN-GW-Address AVP within the CCR command to the H-PCRF. The H-PCRF 
also follows the same procedures in determining whether to include AN-GW-Address AVP or not in the CCA 
command. 

3) Upon QoS rule provisioning: 

When provisioning different QoS rules, the H-PCRF shall include the different QoS rules within separate RAR 
commands, and shall also include the AN-GW-Address AVP with the value set to the BBERF address to 
indicate the actual BBERF where the rules are to be applied. The H-PCRF may also include subscription for any 
event trigger by including the Event-Trigger AVP with the corresponding value. For case 2a, the AN-GW- 
Address AVP is included at the command level; for case 2b, the AN-GW-Address AVP is included at the 
subsession level. 

When provisioning the same QoS rules to all the BBERFs, the H-PCRF shall include the QoS rules within the 
same RAR command without including the AN-GW-Address AVP. 

NOTE: For case 2b the old BBERF always initiates the termination of the Gateway Control Session. 

4.5.3 Visited Access 

4.5.3.1 Request PCC and QoS Rules 

The V-PCRF shall request for PCC or QoS rules from the H-PCRF in the following instances: 

1) A Diameter CCR command as defined in clause 4.5.1 of 3GPP TS 29.212 [3] is received by the V-PCRF from 
the PCEF requesting PCC Rules for a roaming user and/or informing that an installed event trigger has been 
detected in this case the affected PCC Rules are included by the PCEF. 

2) A Diameter CCR command as defined in clause 4a.5. 1 of 3GPP TS 29.212 [3] is received by the V-PCRF from 
the BBERF requesting QoS Rules for a roaming user and/or informing that an installed event trigger has been 
detected in this case the affected QoS Rules are included by the BBERF. The procedures within clause 4.5.3.5 
shall be applied if during a multiple BBERF scenario the request is coming from a non-primary BBERF. 

Editor"s Note: It is FFS if the V-PCRF stores the information received in the CCR from the BBERF and send a 
CCA back to the BBERF without QoS rules to acknowledge the reception of the related CCR 
command. 

The V-PCRF shall store the information received in the CCR command from the BBERF/PCEF and send a new request 
over S9 as follows: 

If an existing S9 session for the roaming user does not already exist with the H-PCRF, the V-PCRF shall 
establish a new S9 session with the H-PCRF by sending a CCR command with the CC-Request-Type AVP set to 
the value 'INITIAL_REQUEST', to the H-PCRF. 

If an existing S9 session for the roaming user is already established with the H-PCRF, the V-PCRF shall update 
the existing session by sending a CCR command with the CC-Request-Type AVP set to the value 
"UPDATE_REQUEST" to the H-PCRF. 
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The V-PCRF shall include within the CCR command those attributes provided by the BBERF and PCEF as defined in 
clause 4a.5.1 and 4.5.1 of 3GPPTS 29.212 [3] respectively. 

- In case 2a if the original CCR command is received from the BBERF, the V-PCRF shall include the attributes 
provided by the BBERF at the Diameter CCR command level. If the original CCR command is received from 
the PCEF, the V-PCRF shall include the attributes provided by the PCEF at the S9 subsession level by including 
the Subsession-Enforcement-Info AVP with the corresponding Subsession-Id AVP. 

In case 2b, the V-PCRF shall refer the request to the corresponding S9 subsession by including, within the CCR 
command the Subsession-Enforcement-Info AVP with the corresponding Subsession-Id AVP and shall also 
include those attributes provided by the BBERF/PCEF. 

For both case 2a and case 2b, 

If new subsessions are created the V-PCRF shall include within the Subsession-Enforcement-Info AVP, the 
Subsession-Id AVP set to the value of a new subsession identifier, the Subsession-Operation AVP set to the 
value "ESTABLISHMENT". The V-PCRF shall map the Gxx or Gx session-id(s) to the corresponding 
subsession-id(s) in the S9 session. 

NOTE: For case 2a, a new subsession will be created only when the original received Diameter CCR from the 

PCEF indicates an establishment request for a new Gx session. This is applicable also to case 2b although 
alternatively, the new subsession might be created upon the reception of the gateway control session 
establishment and be further modified when the corresponding IP-CAN session establishment arrives to 
the V-PCRF. 

If already existing subsessions are modified the V-PCRF shall set the Subsession-Operation AVP value within 
the Subsession-Enforcement-Info AVP to "MODIFICATION". 

If the H-PCRF is, due to incomplete, erroneous or missing information (e.g. subscription related information not 
available or authorized QoS exceeding the subscribed bandwidth) not able to: 

1) Provision a policy decision to one or more of the S9 subsession(s) within the CCR command sent by the V- 
PCRF, the H-PCRF shall send a CCA command including the S9 specific experimental result code 
DIAMETER_ERROR_SUBSESSION (5470) at the command level. For each of the rejected subsessions, the H- 
PCRF shall include the Subsession-Decision-Info AVP with the rejected Subsession-Id within the Subsession-Id 
AVP and the appropriate error code within either the Experimental-Result-Code AVP or Result-Code AVP. For 
each of the successful subsessions, the H-PCRF shall include the Subsession-Decision-Info AVP with the 
corresponding Subsession-Id AVP and any PCC rules to be provisioned. 

2) Provision a policy decision to a CCR command sent by the V-PCRF with no S9 subsession information, the H- 
PCRF shall reject the request using a CCA command with the DIAMETER_ERROR_INITIAL_PARAMETERS 
(5140) within the Experimental-Result-Code AVP. 

NOTE: CCR command with no subsession information is only used in case 2a. 

When the V-PCRF receives a CCA command with an error code within the Experimental-Result-Code AVP or Result- 
Code AVP at the command level, the V-PCRF shall reply to the BBERF over the corresponding gateway control 
session with a CCA command including the same result code. 

When the V-PCRF receives a CCA command including QoS rules at command level, with no subsession information 
and indicating success status at the command level, the V-PCRF shall validate the QoS rules contained in the CCA. If 
the QoS validation fails the V-PCRF shall perform the following: 

1) Reply to the BBERF over Gxx with a CCA command including the Gx experimental result code 
DIAMETER_ERROR_INITIAL_PARAMETERS (5 140). 

2) Send a CCR command to the H-PCRF including the QoS -Rule-Report AVP to indicate the QoS Rules that were 
not accepted, the Rule-Failure-Code AVP set to UNSUCCESSFUL-QOS-VALIDATION, and the QoS- 
Information AVP to indicate the acceptable QoS. 

When the V-PCRF receives a CCA command including QoS rules at command level, with no subsession information 
and indicating success status at the command level and if the QoS validation is successful, the V-PCRF shall follow the 
procedures described in 3GPP TS 29.212 [3] to provision the QoS rules to the BBERF. If after provisioning the QoS 
rules to the BBERF, the V-PCRF receives a notification from the BBERF informing that an operation on one or more 
QoS rule has failed, the V-PCRF shall immediately inform the H-PCRF. The V-PCRF shall send a CCR command with 
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the CC-Request-Type AVP set to the value UPDATE_REQUEST to the H-PCRF including the QoS -Rule-Report AVP 
to indicate the QoS rules that were affected at the command level. The H-PCRF may decide to reinstall, modify or 
remove the affected QoS rules as described in this clause or terminate the S9 session/subsession as described in clause 
4.5.3.4. 

When the V-PCRF receives a CCA command where the S9 specific subsession contains a specific error code within a 
Result-Code or Experimental-Result-Code AVP from the H-PCRF, the V-PCRF shall inform the trigger(s) of the 
related CCR command (i.e. BBERF and/or PCEF) with a CCA command including the same result code. 

When the V-PCRF receives a CCA command where the S9 specific subsession indicates success status, the V-PCRF 
shall validate the PCC rules contained in the CCA. If the validation fails, the V-PCRF shall perform the following: 

1) if the original CCR was received from a BBERF, reply to the BBERF over the corresponding gateway control 
session with a CCA command including the Gx experimental result code 

DIAMETER_ERROR_INITIAL_PARAMETERS (5140), or if the original CCR was received from a PCEF, 
reply to the PCEF over the corresponding Gx session with a CCA command including the same result code. 

2) Send a CCR command to the H-PCRF including Subsession-Enforcement-Info AVP with the corresponding 
Subsession-Id and include the Charging-Rule-Report AVP to indicate the PCC Rules that were not accepted, the 
Rule-Failure-Code AVP set to UNSUCCESSFUL-QOS-VALIDATION, and the QoS -Information AVP to 
indicate the acceptable QoS. The V-PCRF shall set the Subsession-Operation AVP to the value 
'TERMINATION' if the CCR used to request the rules was creating a new subsession. 

When the V-PCRF receives a CCA command where the S9 specific subsession indicates success status and if the QoS 
validation is successful, the V-PCRF shall derive QoS rules based on the PCC rules received. The V-PCRF shall follow 
the procedures described in 3GPP TS 29.212 [3] to provision the PCC/QoS rules to the PCEF and BBERF respectively 
using, if the PCEF/BBERF sent the original CCR command, CCA command or, if the PCEF/BBERF did not send the 
original CCR command, RAR command. 

NOTE: Provisioning rules within RAR command can be needed for those cases when the V-PCRF receives CCR 
command related with a particular event from only the BBERF or only the PCEF. For example, an event- 
trigger such as QOS_CHANGE can trigger only the BBERF to send the CCR command while an event- 
trigger such as OUT_OF_CREDIT can trigger only the PCEF to send the CCR command. 

If after provisioning the rules to the PCEF/BBERF, the V-PCRF receives a notification from the PCEF (case 1, 2a, 2b) 
or the BBERF (case 2a and 2b) or both the PCEF and the BBERF informing that an operation on a PCC/QoS rule has 
failed, the V-PCRF shall inform the H-PCRF. The V-PCRF shall send a CCR command with the CC-Request-Type 
AVP set to the value UPDATE_REQUEST to the H-PCRF including the Charging-Rule-Report AVP to indicate the 
PCC rules that were affected at the subsession level by including the Subsession-Enforcement-Info AVP identifying the 
affected S9 subsession within the Subsession-Id AVP, the Subsession-Operation AVP set to the value 
'MODIFICATION'. The H-PCRF may decide to reinstall, modify or remove the affected PCC rules as described in this 
clause or terminate the S9 session/subsession as described in clause 4.5.3.4. 

4.5.3.2 PCC and QoS Rules Provisioning 

The H-PCRF shall provision, via the S9 reference point, PCC and QoS rules, using one of the following procedures: 

PULL procedure (Provisioning solicited by the V-PCRF): In response to a request for PCC rules being made by 
the V-PCRF, as described in the preceding section, to provide QoS rules for case 2a where no corresponding 
PCC rules are sent, the H-PCRF shall provision QoS rules in the CCA by including the QoS-Rule-Install AVP at 
the command level; for other cases, the H-PCRF shall provision PCC rules in the CCA command by including 
the Charging-Rule-Install AVP within the Subsession-Decision-Info AVP on the S9 subsession(s) that requested 
for PCC rules, or in response to a request for PCC Rules being made by the V-PCRF, as described in the 
preceding section instance 

PUSH procedure (Unsolicited provisioning from the H-PCRF). The H-PCRF may decide to provision (install, 
modify ore remove) PCC Rules without obtaining a request from the V-PCRF, e.g. in response to information 
provided to the H-PCRF from the AF (either in the visited or in the home network), or in response to an internal 
trigger within the H-PCRF, or from a trigger by the SPR. To install or modify PCC Rules without a request from 
the V-PCRF for case 2a when no corresponding PCC rules are sent, the H-PCRF shall provision QoS rules in the 
RAR by including the QoS-Rule-Install AVP at the command level; to provision PCC Rules without a request 
from the V-PCRF, the H-PCRF shall include these PCC Rules in an RAR command by including the Charging- 
Rule-Install AVP on the related S9 subsessions within the Subsession-Decision-Info AVP. To remove installed 
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PCC Rules without a request from the V-PCRF, the H-PCRF shall include these PCC Rules in a RAR command 
by including the Charging-Rule-Remove AVP on the related S9 subsessions within the Subsession-Decision- 
Info AVP. 

The V-PCRF shall validate the QoS information contained within the PCC rules of the CCA/RAR command. If the QoS 
validation fails or other error conditions occur for PCC rules provisioned within the CCA command from the H-PCRF, 
the V-PCRF shall follow the procedures specified in clause 4.5.3.1 for error handling. Otherwise, if the QoS validation 
fails or other error conditions occur when provisioning PCC rules using the RAR command, the procedures below 
apply. 

If the QoS information is provisioned at the command level and the validation fails, the V-PCRF shall respond back to 
the H-PCRF by issuing an RAA command that includes, at the command level, the DIAMETER_PCC_RULE_EVENT 
(5142) experimental result code, the QoS -Rule-Report AVP to indicate the QoS Rules that were not accepted, the Rule- 
Failure-Code AVP set to UNSUCCESSFUL-QOS-VALIDATION, and the QoS-Information AVP to indicate the 
acceptable QoS. 

If the QoS information is provisioned at the command level and the validation is successful, the V-PCRF shall follow 
the procedures described in 3GPP TS 29.212 [3] to provision the QoS rules to the BBERF. If after provisioning the 
rules to the BBERF, the V-PCRF receives a notification from the BBERF informing that an operation on a QoS rule has 
failed, the V-PCRF shall immediately inform the H-PCRF. The V-PCRF shall send a RAA command to the H-PCRF 
including the QoS-Rule-Report AVP to indicate the QoS rules that were affected at the command level. The H-PCRF 
may decide to reinstall, modify or remove the affected Rules as described in this clause or terminate the S9 
session/subsession as described in clause 4.5.3.4. If the provisioning of the rules was successful, the V-PCRF shall 
inform the H-PCRF by sending a RAA command containing, at the command level, the information included in the 
notification received from the BBERF. 

If the QoS information is provisioned at the subsession level and the validation for all subsession fails, the V-PCRF 
shall send a RAA command to the H-PCRF, including the Subsession-Enforcement-Info AVP for each rejected S9 
subsession. Each Subsession-Enforcement-Info AVP includes the rejected Subsession-Id, a 

DIAMETER_PCC_RULE_EVENT (5142) experimental result code, the Charging-Rule-Report AVP to indicate the 
PCC Rules that were not accepted, the Rule-Failure-Code AVP set to UNSUCCESSFUL-QOS-VALIDATION, and the 
QoS -Information AVP to indicate the acceptable QoS. 

If the QoS information is provisioned at the subsession level and the validation for one or more subsession is successful, 
the V-PCRF shall provision the validated rules to the PCEF/BBERF first. For all validated PCC rules, the V-PCRF 
derives QoS rules based on the PCC rules. The V-PCRF follows the procedures specified in 3GPP TS29.212 [3] to 
provision the rules to the BBERF/PCEF. 

If after provisioning the rules to the PCEF/BBERF, the V-PCRF receives a notification from either the PCEF (case 1, 
2a, 2b) or the BBERF (case 2a and 2b) informing that an operation on a PCC/QoS rule has failed, the V-PCRF shall 
inform the H-PCRF. 

After obtaining the QoS validation and rules installation (if applicable) result, the V-PCRF shall send a RAA command 
to the H-PCRF and for each subsession, include the Subsession-Enforcement-Info AVP with the Subsession-Id AVP. In 
addition, for each subsession, the Subsession-Enforcement-Info shall include, 

- if the QoS validation failed at the V-PCRF, a DIAMETER_PCC_RULE_EVENT (5 142) experimental result 
code, the Charging-Rule-Report AVP to indicate the PCC Rules that were not accepted, the Rule-Failure-Code 
AVP set to UNSUCCESSFUL-QOS-VALIDATION, and the QoS-Information AVP to indicate the acceptable 
QoS. 

if the V-PCRF received notification from the BBERF/PCEF indicating failure in provision, the Experimental- 
Result-Code AVP or Result-Code AVP received from the PCEF if available or from the BBERF otherwise, the 
Charging-Rule-Report AVP to indicate the failed PCC Rules, and any other additional information received from 
the BBERF/PCEF. 

if the provision was successful, the result-code and other information received from the PCEF/BBERF. 

The result code or the experimental result code at the RAA command level shall be set to the following value: 

DIAMETER_SUCCESS (2001), if all subsessions have been provisioned successfully; 

- DIAMETER_ERROR_SUBSESSION (5470), if one or more S9 subsessions have failed. 
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For failed PCC rules, the H-PCRF may decide to reinstall, modify or remove the affected PCC Rules as described in 
this clause or terminate the S9 session/subsession as described in clause 4.5.3.4. 

4.5.3.3 S9 Session/Subsession Termination Initiated by V-PCRF. 

When the V-PCRF receives an indication of an IP -CAN Session Termination from the PCEF or an indication of Gxx 
session termination from the BBERF, the V-PCRF shall acknowledge the received message by sending the CCA 
command to the PCEF or the BBERF as defined in 3GPP TS 29.212 [3]. In addition, the V-PCRF shall indicate to the 
H-PCRF one of the following actions: 

1) Terminate the S9 session, if in case 2a, the Gxx session is removed or in case 2b, the last S9 subsession for the 
roaming user is removed. The V-PCRF shall terminate the S9 session with the H-PCRF by sending a CCR with 
the CC-Request-Type AVP set to the value "TERMINATION_REQUEST'. 

2) Update the S9 session for the roaming user, if there are remaining S9 subsessions for the roaming user. The V- 
PCRF shall update the existing S9 session with the H-PCRF by sending a CCR command with CC-Request-type 
AVP set to value 'UPDATE-REQUEST' that includes the Subsession-Enforcement-Info AVP with the removed 
S9 subsession identifier within the Subsession-Id AVP, the Subsession-Operation AVP set to the value 
'TERMINATION'. 

NOTE: In case 2b, when the V-PCRF receives a Gxx session termination request from the BBERF (i.e. a CCR 
command with CC-Request-Type AVP set to value 'TERMINATION_REQUEST') , it handles it as 
specified in 3GPP TS 29.212 [3] without impacting S9. 

When receiving the CCR command, the H-PCRF shall perform the following steps: 

1) Identify the removed PCC Rules associated to the terminated S9 session or S9 subsession; 

2) If an IP-CAN session is terminated, check whether the H-AF shall be informed and if the H-AF needs to be 
informed, send an ASR command as defined in clause 4.4.6.1 of 3GPP TS 29.214 [5] 

The H-PCRF answers to the V-PCRF by issuing a CCA command. 

4.5.3.4 S9 Session/Subsession Termination Initiated by the H-PCRF. 

The H-PCRF may decide to terminate an S9 session or S9 subsession based on an internal trigger or a trigger from the 
SPR. When any of these triggers are met, the H-PCRF shall initiate a S9 session or S9 subsession termination by 
sending an RAR command to the V-PCRF as defined in clause 4.5.2.4. 

4.5.3.5 Multiple BBERF Handling 

The V-PCRF distinguishes two types of BBERF: primary and non-primary according to 3GPP TS 29.212 [3]. 

The V-PCRF shall ensure that the QoS rules are aligned with the PCC rules on all BBERFs as specified in TS 29.212 
[3] clause 4a.5.7 

The V-PCRF shall handle Gateway control session establishment and Gateway QoS request messages from a new 
BBERF locally. 

When, due to handover, the V-PCRF receives an IP CAN session modification from the PCEF with the event trigger set 
to AN_GW_CHANGE the V-PCRF shall send a CCR message to the H-PCRF with the Event-Trigger AVP at 
subsession level set to AN_GW_CHANGE, provided the H-PCRF has subscribed to this event-trigger. If the CCR 
message from the PCEF also includes the IP-CAN_CHANGE event-trigger, the V-PCRF shall reclassify the primary/ 
non-primary BBERFs based on the received IP-CAN type, and shall include this trigger as well in the CCR message 
sent to the H-PCRF, provided the H-PCRF has subscribed to it. If there is any subsequent request coming from the 
primary BBERF, the V-PCRF shall act according to the normal procedures specified in clause 4.5.3 and corresponding 
subclauses. 

If the H-PCRF has not subscribed to either the AN_GW_CHANGE or the IP-CAN_CHANGE event, the V-PCRF shall 
not inform the H-PCRF of this scenario and should solve it according to local policies and roaming agreements. 
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4.5.3.6 Rx Over S9 

4.5.3.6.1 General 

The interaction between the V-AF and the V-PCRF is in accordance with 3GPP TS 29.214 [5]. The V-PCRF may act as 
a Diameter Proxy or client/server to send the Rx messages between the V-AF and the H-PCRF except as noted below. 

The V-PCRF may process the initial or modified Service Information received from the V-AF according to the operator 
policy to decide whether the request is accepted or not. If the service information provided by the V-AF is rejected, the 
V-PCRF shall send the AAA to reject the request with the Experimental-Result-Code AVP set to the value 
REQUESTED_SERVlCE_NOT_AUTHORlZED. In this case, the V-PCRF shall not forward the AAR to the H-PCRF. 

The V-PCRF shall not forward the AAR message from the V-AF to the H-PCRF if the processing of the request results 
in any of the specific values of the 'Rx specific Experimental-Result-Code' per clause. 5.5 of 3GPP TS 29.214 [5]. 

Editor"s Note: Optimization of the AF signalling channel and handling of the AF subscription events is FFS. 

4.5.3.6.2 Event Handling 

4.5.3.6.2.1 V-AF Subscription to Notification of Signalling Path Status 

A V-AF may subscribe to notifications of the status of the AF Signalling transmission path by including the Specific- 
Action AVP with the corresponding value as described in section 4.4.5 of 3GPP TS 29.214 [9]. 

When the V-PCRF receives an AAR command for the establishment of the AF signalling session from the V-AF, the 
V-PCRF, depending on operator policy, may not forward the AAR message to the H-PCRF. In this case, the V-PCRF 
handles the AF signalling session locally and shall acknowledge the AAR command by sending an AAA command to the V- 
AF and follow the procedures described in clause 4.4.5 of 3GPP TS 29.212 [9]. Otherwise, the V-PCRF proxies the 
AAR to the H-PCRF. 

Editor" s note: It is FFS how to handle the AF signalling transmission path locally if, for non-IMS V-AF, the 
AAR message from the V-AF includes both AF signalling and service information. 

4.5.3.6.2.2 Reporting of Signalling Path Status 

If the V-PCRF is handling the AF signalling session locally with the V-AF (i.e. the V-PCRF is not proxying the AF 
signalling session to the H-PCRF) and subscribed to the signalling path status specific actions 

("INDlCATION_OF_LOSS_OF_BEARER" and/or 'IND1CAT10N_0F_RELEASE_0F_BEARER'), and the V-PCRF 
is notified of the loss or release of resources associated to the PCC Rules corresponding with V-AF Signalling IP Flows, 
the V-PCRF shall inform the V-AF about the Loss of the Signalling Transmission Path by sending a Re-Authorization 
Request (RAR) command to the V-AF per section 4.4.6.3 of TS 29.214 [9]. 

The V-PCRF shall send a CCR message to the H-PCRF over the S9 interface reporting this event trigger only if the H- 
PCRF has previously subscribed to the corresponding event trigger. 

4.5.3.6.2.3 Reporting IP-CAN Type Change Notification 

If the V-PCRF is handling the AF signalling session locally with the V-AF (i.e. the V-PCRF is not proxying the AF 
signalling session to the H-PCRF) and the V-AF has subscribed for change notification in UE's IP-CAN type, then the 
V-PCRF shall send a RAR command when there is a change in the UE's IP-CAN type per section 4.4.6.4 of TS 29.214 
[9]. 

The V-PCRF shall send a CCR message to the H-PCRF over the S9 interface reporting this event trigger only if the H- 
PCRF has previously subscribed to the corresponding event trigger. 
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5. S9 Protocol 

5.1 Protocol Support 

The S9 application is defined as a vendor specific Diameter application, where the vendor is 3GPP and the Application- 
ID for the S9 Application in the present release is 16777267. The vendor identifier assigned by lANA to 3GPP 
( http://www.iana.org/assignments/enterprise-numbers ) is 10415. 

NOTE: A route entry can have a different destination based on the application identification AVP of the message. 
Therefore, Diameter agents (relay, proxy, redirection, translation agents) must be configured 
appropriately to identify the 3GPP S9 application within the Auth- Application-Id AVP in order to create 
suitable routeing tables. 

Due to the definition of the commands used in the S9 protocol, there is no possibility to skip the Auth-AppUcation-Id 
AVP and use the Vendor-Specific-Application-Id AVP instead. Therefore the S9 application identification shall be 
included in the Auth- Application-Id AVP. 

With regard to the Diameter protocol defined over the S9 interface, the H-PCRF acts as a Diameter server, in the sense 
that it is the network element that handles PCC/QoS rule requests for a particular realm. The V-PCRF acts as the 
Diameter client, in the sense that it is the network element requesting PCC/QoS rules to the H-PCRF. 

A Diameter S9 session used in the S9 protocol shall combine all Gx and Gxx Diameter sessions for a particular UE. 

5.2 Initialization, maintenance and termination of connection 
and session 

The initialization and maintenance of the connection between each V-PCRF/H-PCRF pair is defined by the underlying 
protocol. Establishment and maintenance of connections between Diameter nodes is described in IETF RFC 3588 [6]. 

After establishing the transport connection, the V-PCRF and the H-PCRF shall advertise the support of the S9 specific 
Application by including the value of the application identifier in the Auth- Application-Id AVP and the value of the 
3GPP (10415) in the Vendor-Id AVP of the Vendor-Specific-Application-Id AVP contained in the 
Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The Capabilities-Exchange-Request 
and Capabilities-Exchange-Answer commands are specified in the Diameter Base Protocol (RFC 3588 [6]). 

The termination of the Diameter user session is specified in IETF RFC 3588 [6] in clauses 8.4 and 8.5. The description 
of how to use of these termination procedures in the normal cases is embedded in the procedures description (clause 
4.5). 



5.3 S9 specific AVPs 



Table 5.3.1 describes the Diameter AVPs defined for the S9 reference point, their AVP Code values, types, possible 
flag values, whether or not the AVP may be encrypted and the applicability of the AVPs to charging control, policy 
control or both. The Vendor-Id header of all AVPs defined in the present document shall be set to 3GPP (10415). 
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Table 5.3.1 : S9 specific Diameter AVPs 



Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(note 2) 


AVP Flag rules (note 1) 
Must May Should Must 
not not 


May 
Encr. 


Acc. 
type 


Applica 

bility 
(note 3) 


Subsession-Decision-lnfo 


xxxx 


5.3.1 


Grouped 


M,V 


P 






Y 


All 


Both 


Subsession-Enforcement-lnfo 


xxxx 


5.3.2 


Grouped 


M,V 


P 






Y 


All 


Both 


Subsession-ld 


xxxx 


5.3.3 


Unsigned32 


M,V 


P 






Y 


All 


Both 


Subsession-Operation 


xxxx 


5.3.4 


Enumerated 


M,V 


P 






Y 


All 


Both 


NOTE 1 : The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit 
denoted as 'V, indicates whether the optional Vendor-ID field is present in the AVP header. For further 
details, see RFC 3588 [4]. 

NOTE 2: The value types are defined in RFC 3588 [4]. 

NOTE 3: AVPs marked with 'CC are applicable to charging control, AVPs marked with 'PC are applicable to policy 
control and AVPs marked with 'Both' are applicable to both charging control and policy control. 



5.3.1 Subsession-Decision-lnfo 

The Subsession-Decision-lnfo AVP (AVP code xxxx) is of type Grouped, and it is used to manage PCC/QoS rules and 
event information within an S9 subsession from the H-PCRF to the V-PCRF. 

The information contained within this grouped AVP pertains only to the subsession identified by the Subsession-Id 
AVP. 

The Session-Release-Cause AVP is only applicable when the Subsession-Decision-lnfo AVP is provided in a RAR. 

The Result-Code AVP and Experimental-Result-Code AVP are only applicable when the Subsession-Decision-lnfo 
AVP is provided in a CCA. The Result-Code AVP or Experimental-Result-Code AVP may be provided to inform the 
V-PCRF of possible errors when processing subsession information that was provided in a corresponding CCR 
command. 

AVP Format: 



Subsession-Decision-lnfo 



0*2 



AVP Header: xxxx > 
Subsession-Id } 
AN-GW-Address ] 
Result-Code ] 
Experimental -Result -Code 
Charging-Rule-Remove ] 
Charging-Rule-Install ] 
QoS-Rule-Install ] 
QoS-Rule-Remove ] 
Default-EPS-Bearer-QoS ] 
Session-Release-Cause ] 
Event-Trigger ] 
Online ] 
Offline ] 
QoS-Information ] 
AVP ] 



5.3.2 Subsession-Enforcement-lnfo 

The Subsession-Enforcement-lnfo AVP (AVP code xxxx) is of type Grouped, and it is used to set up and tear down 
subsessions, provide information about the subsession, request PCC/QoS rules and report on PCC/QoS rules and related 
events. This information is sent from the V-PCRF to the H-PCRF.The information contained within this grouped AVP 
pertains only to the subsession identified by the Subsession-Id AVP. 

The following AVPs are only applicable when the Subsession-Enforcement-lnfo AVP is provided within a CCR: 
Subsession-Operation AVP, Bearer-Identifier AVP, Bearer-Operation AVP, Packet-Filter-Information AVP, Packet- 
Filter-Operation AVP, QoS-Information AVP, Framed-IP-Address AVP, Framed-IPv6-Prefix AVP, Called-Station-ID 
AVP, Bearer-Usage AVP, TFT-Packet-Filter-Information AVP, Online AVP and Offline AVP. 

The following AVPs are only applicable when the Subsession-Enforcement-lnfo AVP is provided within an RAA: 
Result-Code AVP and Experimental-Result-Code AVP. 
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The other AVPs are applicable when the Subsession-Enforcement-Info AVP is provided in either a CCR or RAA. 

The Result-Code AVP or Experimental-Result-Code AVP may be provided to inform the H-PCRF of possible errors 
when processing subsession information that was provided in a corresponding RAR command. 

Subsession-Enforcement-Info ::= < AVP Header: xxxx > 

{ Subsession-Id } 

Subsession-Operation ] 
0*2 [ AN-GW-Address ] 

Bearer-Identifier ] 

Bearer-Operation ] 

Packet-Filter-Inf ormation ] 

Packet-Filter-Operation ] 

QoS-Information ] 

Framed- IP-Address ] 

Framed-IPv6-Pref ix ] 

CoA- Information ] 

Called-Station-ID ] 

Bearer-Usage ] 

TFT-Packet-Filter-Information ] 

Online ] 

Offline ] 

Result-Code ] 

Experimental-Result-Code ] 

Charging-Rule-Report ] 

QoS-Rule-Report ] 

Default-EPS-Bearer-QoS ] 

Event -Trigger ] 

Acces s -Network- Charging- Identifier-Gx ] 

AVP ] 

5.3.3 Subsession-Id 

The Subsession-Id AVP (AVP code xxxx) is of type Unsigned32, and it is used to uniquely identify a subsession within 
the S9 session. The Subsession-Id AVP shall be selected by the V-PCRF. 



5.3.4 Subsession-Operation 

The Subsession-Operation AVP (AVP code xxxx) is of type of Enumerated, and it indicates the operation to be 
performed on the subsession. 

The following values are defined: 

TERMINATION (0) 

This value is used to indicate that a subsession is being terminated. 
ESTABLISHMENT (1) 

This value is used to indicate that a new subsession is being established. 
MODIFICATION (2) 

This value is used to indicate that an existing subsession is being modified. 

5.3.5 Void 

5.4 S9 re-used AVPs 

The S9 reference point re-uses all of the Gx and Gxx AVPs specified in 3GPP TS 29.212 [3], including the AVPs re- 
used by Gx and Gxx as specified in clauses 5.4 and 5a.4 of 3GPP TS 29.212 [3]. 

5.4.1 Use of tine Supported-Features AVP on tine S9 reference point 

The Supported-Features AVP is used in S9 commands to inform the destination host about the features that the origin 
host requires to successfully complete a given command exchange. As described in section 7.2 of [7], a request 
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command message shall always be compliant with the list of supported features indicated in the Supported-Features 
AVPs within that command message and features that are not indicated in the Supported-Features AVPs within a given 
application message shall not be used to construct that command message. Unless otherwise stated, the use of the 
Supported-Features AVP on the S9 reference point shall be compliant with the requirements for dynamic discovery of 
supported features on the Cx reference point as defined in section 7.2.1 of [7]. 

The base functionality for the S9 reference point is the 3GPP Rel-8 standard and a feature is an extension to that 
functionality. If the origin host does not support any features beyond the base functionality, the Supported-Features 
AVP may be absent from the S9 commands. 

As defined in [7], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and 
Feature-List AVPs. On the S9 reference point, the Supported-Features AVP is used to identify features that have been 
defined by 3GPP and hence the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple 
feature lists defined for the S9 reference point, the Feature-List-ID AVP shall differentiate those lists from one another. 

5.5 S9 Messages 

5.5.1 S9 Application 

S9 Messages are carried within the Diameter Application(s) described in clause 5.1. 

Existing Diameter command codes from the Diameter base protocol RFC 3588 [5] and the Diameter Credit Control 
Application RFC 4006 [9] are used with the S9 specific AVPs specified in clause 5.3. The Diameter Credit Control 
Application AVPs and AVPs from other Diameter applications that are re-used are defined in clause 5.4. Due to the 
definition of these commands there is no possibility to skip the Auth- Application-Id AVP and use the Vendor-Specific- 
Application-Id AVP instead. Therefore the S9 application identifier shall be included in the Auth- Application-Id AVP. 

NOTE: Some of the AVPs included in the messages formats below are in bold to highlight that these AVPs are 
used by this specific protocol and do not belong to the original message definition in the DCC 
Application RFC 4006 [9] or Diameter Base Protocol RFC 3588 [5]. 

5.5.2 CC-Request (CCR) Command 

The CCR command, indicated by the Command-Code field set to 272 and the 'R' bit set in the Command Flags field, is 
sent by the V-PCRF to the H-PCRF in order to request PCC or QoS rules. The CCR command is also sent by the V- 
PCRF to the H-PCRF in order to indicate bearer or PCC/QoS rule related events. 



Message Format: 



<CC-Request> 



0*2 



Diameter Header: 272, REQ, PXY > 
Session-Id > 
Auth-Application-Id } 
Origin-Host } 
Origin-Realm } 
Destination-Realm } 
CC-Request-Type } 
CC-Request-Number } 
Destination-Host ] 
Origin-State-Id ] 
Subscription-Id ] 
Framed- IP-Address ] 
Framed-IPv6-Pref ix ] 
Supported-Features ] 
QoS- Information ] 
TFT-Packet-Filter-Information ] 
QoS-Rule-Report ] 
AN-GW-Address ] 
Network-Request-Support ] 
Packet-Filter-Information ] 
Packet-Filter-Operation ] 
Subsession-Enforcement-Info ] 
IP-CAN-Type ] 
RAT-Type ] 
Termination-Cause ] 
User- Equipment -Info ] 
QoS-Negotiation ] 
QoS-Upgrade ] 
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[ 3GPP-SGSN-MCC-MNC ] 

[ 3GPP-SGSN-Address ] 

[ 3GPP-SGSN-IPv6-Address ] 

[ RAI ] 

[ 3GPP-User-Location-Info] 

[ 3GPP2-BSID ] 

* [ Event-Trigger] 
* [ Proxy- Info ] 

* [ Route-Record ] 

* [ AVP ] 

5.5.3 CC-Answer (CCA) Command 

The CCA command, indicated by the Command-Code field set to 272 and the 'R' bit cleared in the Command Flags 
field, is sent by the H-PCRF to the V-PCRF in response to the CCR command. It is used to provision PCC/QoS rules 
and event triggers for the subsession/session 

Message Format: 



<CC-Answer> 



Diameter Header: 272, PXY : 
Session-Id > 
Auth-Application-Id } 
Origin-Host } 
Origin-Realm } 
Result-Code ] 
Experimental-Result ] 
CC-Request-Type } 
CC-Request-Number } 
Supported- Features] 
QoS-Rule-Install ] 
QoS-Rule-Remove ] 
QoS- Information ] 
Bearer- Control -Mode ] 
Event-Trigger ] 
Charging- Information ] 
Subsession-Decision-Info ] 
AN-GW-Address ] 
Origin-State-Id ] 
Error-Message ] 
Error-Reporting-Host ] 
Failed-AVP ] 
Proxy- Info ] 
Route-Record ] 
AVP ] 



5.5.4 Re-Auth-Request (RAR) Command 

The RAR command, indicated by the Command-Code field set to 258 and the 'R' bit set in the Command Flags field, is 
sent by the H-PCRF to the V-PCRF in order to provision QoS/PCC rules and event triggers for the subsession/session. 

Message Format: 



<RA-Request> ::= < Diameter Header: 258, REQ, PXY 

< Session-Id > 

{ Auth-Application-Id } 

{ Origin-Host } 

{ Origin-Realm } 

{ Destination-Realm } 

{ Destination-Host } 

{ Re-Auth-Request-Type } 

[ Origin-State-Id ] 

*[ Supported-Features] 

*[ QoS-Rule-Install ] 

* [ QoS-Rule-Remove ] 

*[ QoS- Information ] 

* [ Event-Trigger ] 

*[ Subsession-Decision-Info ] 

0*2 [ AN-GW-Address ] 

* [ Proxy- Info ] 

* [ Route-Record ] 

* [ AVP] 
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5.5.5 Re-Auth-Answer (RAA) Command 



The RAA command, indicated by the Command-Code field set to 258 and the 'R' bit cleared in the Command Flags 
field, is sent by the V-PCRF to the H-PCRF in response to the RAR command. 



Message Format: 






<RA-Answer> : : = 


< 


Diameter Header: 258, PXY > 




< 


Session-Id > 






Origin-Host } 






Origin-Realm } 
Result-Code ] 
Experimental-Result ] 
Origin-State-Id ] 
Framed- IP-Address ] 
Framed-IPv6-Pref ix ] 




* [ 


Supported- Features] 
QoS- Information ] 




* [ 


TFT-Packet-Filter-Information ] 




* [ 


QoS-Rule-Report ] 





*2[ 


AN-GW-Address ] 




* [ 


Subsession-Enforcement-Info ] 

Error-Message ] 
Error-Reporting-Host ] 




* [ 


Failed-AVP ] 




* [ 


Proxy- Info ] 




* [ 


AVP ] 



5.6 S9 specific Experimental-Result-Code AVP values 

5.6.1 General 

RFC 3588 [6] specifies the Experimental-Result AVP containing Vendor-ID AVP and Experimental-Result-Code AVP. 
The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32 and contains a vendor-assigned value 
representing the result of processing a request. The Vendor-ID AVP shall be set to 3GPP (10415). 

5.6.2 Success 

Result Codes that fall within the Success category are used to inform a peer that a request has been successfully 
completed. 

The Result-Code AVP values defined in Diameter BASE RFC 3588 [6] shall be apphed. 

5.6.3 Permanent Failures 

Errors that fall within the Permanent Failures category shall be used to inform the peer that the request failed, and 
should not be attempted again. 

The Result-Code AVP values defined in Diameter BASE RFC 3588 [6] and 3GPP TS 29.212 [3] are appUcable. Also 
the following specific S9 Experimental-Result-Codes values are defined: 

DIAMETER_ERROR_SUBSESSION (5470) 

This error shall be used when one or more S9 subsessions within the answer contains an unsuccessful Result- 
Code or Experimental-Result-Code value. The Result Code specific to the request related to the subsession is 
specified within the corresponding Subsession-Decision-Info or Subsession-Enforcement-Info AVP. 
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